[% setvar title The Perl 6 Summary for the week ending 20040125 %]
<div id="archive-notice">
    <h3>This file is part of the Perl 6 Archive</h3>
    <p>To see what is currently happening visit <a href="http://www.perl6.org/">http://www.perl6.org/</a></p>
</div>
<div class='pod'>
<a name='The Perl 6 Summary for the week ending 20040125'></a><h1>The Perl 6 Summary for the week ending 20040125</h1>
<p>Welcome to the first summary from my new home in Gateshead. The same
old wibble, with a different view from its window and fewer trips to
London. Right, time to see what's been going on in perl6-internals
this week.</p>
<a name='Global labels in IMCC'></a><h2>Global labels in IMCC</h2>
<p>The cryptically named TOGoS wondered how to get the address of a label
in a different IMCC compilation unit. According to Dan there's no way
to do that, and you didn't want to do that anyway.</p>
<p><a href='http://groups.google.com/groups?selm=20040119201611.71859.qmail@web41408.mail.yahoo.com' target='_blank'>groups.google.com</a></p>
<a name='Dan's threads proposal'></a><h2>Dan's threads proposal</h2>
<p>After a few weeks of everyone else's proposals, Dan started to outline
the design of Parrot's threading capabilities. He started by defining
his terms (a useful thing to do in a field where there seem to me
multiple competing definitions of various terms) and guaranteeing that
user code wouldn't crash the interpreter (subject to the assumption
that system level memory allocation was thread safe) before getting
into the meat of his proposal. Which you're probably best reading for
yourself; it's a long document but there's very little flab and any
attempt of mine to summarize it would probably end up being at least
as long as and a good deal less lucid than the original.</p>
<p>Of course, this sparked a ton of discussion, generally positive, as
people asked for various clarifications and made suggestions. Gordon
Henriksen pointed out a nasty race condition that means that the
garbage collector can't be made as thread safe as Dan had hoped.</p>
<p>Summarizer Barbie says &quot;Threads are hard!&quot;</p>
<p>On Thursday, Dan posted a last call for comments and objections before
he went on to the detailed design. This time there were some
objections, but I don't think any of 'em are going to stop
Dan.</p>
<p><a href='http://groups.google.com/groups?selm=a0601020dbc31eb8d1b67@' target='_blank'>groups.google.com</a>[10.0.1.2]</p>
<p><a href='http://groups.google.com/groups?selm=a06010210bc35dbe3d5bf@' target='_blank'>groups.google.com</a>[10.0.1.4]</p>
<a name='Vtables organization'></a><h2>Vtables organization</h2>
<p>Last week Dan had outlined an approach to organizing PMC vtables using
a chaining approach; this week saw the discussion of that proposal
with Benjamin K. Stuhl asking the hard questions.</p>
<p><a href='http://groups.google.com/groups?selm=400BDD81.1060909@cornell.edu' target='_blank'>groups.google.com</a></p>
<a name='Benchmark suite'></a><h2>Benchmark suite</h2>
<p>Matt Fowles suggested that it might make sense to create a canonical
suite of benchmarks to exercise Parrot well. His idea being that, if
we have a standard suite of Parrot benchmarks, then potential
performance affecting changes could be tested against that, rather
than having custom benchmarks rolled each time. Luke Palmer pointed to
<b><i>examples/benchmarks</i></b> and noted that it's hard to create benchmarks
that test everything. However, he hoped that any good benchmark that
gets posted to the list would get added to this suite, along with some
documentation describing what is being tested.</p>
<p><a href='http://groups.google.com/groups?selm=40144AE1.9050205@softhome.net' target='_blank'>groups.google.com</a></p>
<a name='Number formatting'></a><h2>Number formatting</h2>
<p>Dan did some more designing, this time mandating that Parrot will,
eventually adopt ICU's formatting template for numeric templates but,
to start with, we'll be rolling our own. The new op will be <code>format
Sx, [INP]y, [SP]z</code>.</p>
<p><a href='http://groups.google.com/groups?selm=a06010210bc31f337e755@' target='_blank'>groups.google.com</a>[10.0.1.2]</p>
<a name='Base string transforms'></a><h2>Base string transforms</h2>
<p>Dan announced that he would be adding <code>upcase</code>, <code>downcase</code>,
<code>titlecase</code> and <code>to_chartype</code> to the various chartype vtables. He
also noted that he'd like to get some alternative chartypes and
encodings into Parrot as soon as possible to make sure we can actually
handle things without having to use Unicode all the time.</p>
<p><a href='http://groups.google.com/groups?selm=a06010211bc31f77ae6da@' target='_blank'>groups.google.com</a>[10.0.1.2]</p>
<a name='Calling conventions in IMCC'></a><h2>Calling conventions in IMCC</h2>
<p>Will Coleda had some problems with IMCC's handling of the parrot
calling conventions when he found that code that worked a couple of
months ago had stopped working in the current Parrot (A month is a
*very* long time in Parrot development though.) The problem took a
fair bit of tracking down and I'm not entirely sure it's entirely
fixed yet; Will had reached the point where the code would compile,
but it still wouldn't actually run.</p>
<p><a href='http://groups.google.com/groups?selm=B8548E4C-4AA8-11D8-95BB-000A95909DD0@coleda.com' target='_blank'>groups.google.com</a></p>
<a name='Steve Fink's obnoxious test case'></a><h2>Steve Fink's obnoxious test case</h2>
<p>Steve Fink posted an obnoxious test case that generated memory
corruption. The test case is obnoxious because it's 56KB of IMCC source
code, and Steve had been unable to reduce it. This didn't discourage
Leo T&ouml;tsch though, who set about tracking the bug to its
lair. It's not fixed yet, but with the Patchmonster on the case it can
only be a matter of time.</p>
<p>There were several other GC related issues that cropped up over the
week; I wonder if they're all aspects of a single lurking bug.</p>
<p><a href='http://groups.google.com/groups?selm=20040120004855.GA28881@foxglove' target='_blank'>groups.google.com</a></p>
<a name='IMCC returning ints'></a><h2>IMCC returning ints</h2>
<p>Steve Fink also found a problem with IMCC failing to properly return
integers from unprototyped routines and posted an appropriate patch
to the test suite. It turns out that the problem is that IMCC doesn't
quite implement the full Parrot Calling Conventions, especially the
return convention, but it's getting there.</p>
<p><a href='http://groups.google.com/groups?selm=20040120015843.GC27636@foxglove' target='_blank'>groups.google.com</a></p>
<a name='The costs of sharing'></a><h2>The costs of sharing</h2>
<p>Leo T&ouml;posted a test program and some results for timing the
difference between using shared and unshared PMCs. The shared versions
are (not surprisingly) slower than the unshared ones; the question is
whether the difference between the two can be improved. Hopefully the
benchmark will get checked into <b><i>examples/benchmarks</i></b> as suggested by
Luke earlier.</p>
<p><a href='http://groups.google.com/groups?selm=400D5BD3.1020409@toetsch.at' target='_blank'>groups.google.com</a></p>
<a name='An array of array types'></a><h2>An array of array types</h2>
<p>Dan noted that we have &quot;a pile of different array classes with fuzzy
requirements and specified behaviours which sort of inherit from each
other except when they don't.&quot; He suggested that the time had come to
work out what we actually <i>want</i> in the way of array classes, compare
our requirements with what we have, and then to do something about
making what was available match what was required. I'm not sure that
the resulting discussion has finalized the set of array types needed,
but it's getting there. (Does anyone else think 'FixedMixedArray' is
awfully clumsy as names go?).</p>
<p><a href='http://groups.google.com/groups?selm=a0601020ebc3350821beb@' target='_blank'>groups.google.com</a>[10.0.1.2]</p>
<a name='Remember to nag Robert Spier'></a><h2>Remember to nag Robert Spier</h2>
<p>Robert Spier announced that repairing the web accessible TODO list was
on his personal TODO list and asked to be nagged about it
periodically.</p>
<p>Robert, remember you need to fix the web accessible TODO list.</p>
<p><a href='http://groups.google.com/groups?selm=m3k73mw9fa.wl_rspier@pobox.com' target='_blank'>groups.google.com</a></p>
<a name='Churchill's parrot still swearing'></a><h2>Churchill's parrot still swearing</h2>
<p>Effortlessly Godwinning himself, Uri Guttman pointed to a press
release which stated that Winston Churchill's parrot, Charlie, is now
104 years old and can still be coaxed into squawking &quot;Fuck Hitler&quot; and
&quot;Fuck the Nazis&quot; which had apparently made it rather unsuitable for
keeping at its owner's pet shop due to its habit of swearing at children.</p>
<p><a href='http://groups.google.com/groups?selm=x7d69eey3y.fsf@mail.sysarch.com' target='_blank'>groups.google.com</a></p>
<a name='Updated documentation in Perl scripts'></a><h2>Updated documentation in Perl scripts</h2>
<p>Michael Scott continued his sterling work of updating and generally
improving Parrot's documentation. This week his attention fell upon:
the Perl scripts found in <b><i>build_tools</i></b>, <b><i>classes</i></b> and
<b><i>tools/dev</i></b>. Top man that he is, he's currently working on the
documentation embedded in C code.</p>
<p><a href='http://groups.google.com/groups?selm=051BEB2F-4B99-11D8-86A0-000A95C50226@mac.com' target='_blank'>groups.google.com</a></p>
<p><a href='http://groups.google.com/groups?selm=a0601021fbc36e6903a5c@' target='_blank'>groups.google.com</a>[10.0.1.4]</p>
<a name='Open issue review'></a><h2>Open issue review</h2>
<p>Robert Spier (don't forget the web accessible todo list Robert) posted
a list of the 177 currently outstanding Parrot issues in the RT
system and asked for volunteers to go through them to help weed out
those issues that were no longer current. So people did. Which is nice.</p>
<p><a href='http://groups.google.com/groups?selm=m3isj6w7c0.wl_rspier@pobox.com' target='_blank'>groups.google.com</a></p>
<a name='How to subclass dynamic PMCs'></a><h2>How to subclass dynamic PMCs</h2>
<p>Michal Wallace is trying to make a dynamically loaded PMC that
subclasses another dynamically loaded PMC and he can't work out how
to do it. Leo T&ouml;tsch had the answer.</p>
<p><a href='http://groups.google.com/groups?selm=Pine.LNX.4.58.0401211335500.19552@hydrogen.sabren.com' target='_blank'>groups.google.com</a></p>
<a name='How does Parrot handle High Level Language eval'></a><h2>How does Parrot handle High Level Language eval</h2>
<p>Nigel Sandever wondered how Parrot would handle <code>eval</code> opcodes for
multiple different languages. Leo pointed him at the <code>compile</code> op,
which (while it isn't fully implemented yet) will address this issue.
Dan noted that it's currently working for PIR and PASM code but that
it should be able to work eventually with any compiler that generates
standard bytecode.</p>
<p><a href='http://groups.google.com/groups?selm=1103_1074823506@nntp.perl.org' target='_blank'>groups.google.com</a></p>
<a name='Signals and events'></a><h2>Signals and events</h2>
<p>Leo is working on turning OS level signals into Parrot level events,
and he's not having an easy time of it. He posted a summary of the
issues and asked for comments. Discussion continues.</p>
<p><a href='http://groups.google.com/groups?selm=4010EB5B.1040608@toetsch.at' target='_blank'>groups.google.com</a></p>
<a name='Threading again'></a><h2>Threading again</h2>
<p>Gordon Henriksen worries that Parrot's current architecture is
actively thread hostile. He also accepted that trying to change it now
wasn't really possible. So he outlined various ways in which the need
for locking could be reduced, which should help speed things up. The
big problem, as Gordon sees it, is that so many Parrot data structures
are mutable, and mutable data structures require locks. And having
PMCs that can morph from one type to another is... well, Gordon claims
that <code>morph</code> must die, though he later modified this claim. He and
Leo batted this back and forth for a while; I'm not sure either side
is convinced.</p>
<p><a href='http://groups.google.com/groups?selm=8A1B28F4-4E28-11D8-85AB-000502994722@mac.com' target='_blank'>groups.google.com</a></p>
<a name='Embedding vs. extending interface types'></a><h2>Embedding vs. extending interface types</h2>
<p>Mattia Barbon noted that the embedding and extending interfaces were
still using different names for <code>Parrot_Interp</code> and
<code>Parrot_INTERP</code>. He wondered which was correct. It turns out that
nobody's quite sure, but the person who can make the decision -- Dan
-- was en route to Copenhagen when this came up, so there's no answer
yet.</p>
<p><a href='http://groups.google.com/groups?selm=Mahogany-0.66.0-920-20040124-172842.00@rbnet.it' target='_blank'>groups.google.com</a></p>
<a name='Meanwhile in perl6-language'></a><h1>Meanwhile in perl6-language</h1>
<a name='Semantics of Vector operations'></a><h2>Semantics of Vector operations</h2>
<p>Determined to test everyone's Unicode readiness, Luke Palmer kicked
off a discussion of the semantics of <code>[1,2,3] »+«
[4,5,6]</code>. At first glance it looks like the result should be
<code>[5,7,9]</code>, but Luke argued that actually, the code was trying to add
two lists, each containing a single scalar, that just happened to be
listrefs. Larry pointed out that &quot;Doing what you expect at first
glance is also called 'not violating the principle of least
surprise'&quot;, before going on to surprise us all with 'lopsided' vector
ops, which would allow the programmer to specify when a value was
expected to be treated as a scalar:</p>
<pre>    $a   »+« $b     # Treat $a and $b as lists
    $x    +« $y     # Treat $x as a scalar and $b as a list
          -« @bar   # Return a list of every element of @bar, negated
    @foo »+  @bar   # Add the length of @bar to every element of @foo</pre>
<p>Then he scared me with <code>@foo »+= @foo</code>. He noted that it might take
some getting used to, but that it helped if you pronounce <code>»</code> and
<code>«</code> as 'each'. Austin Hastings didn't like it (from a syntax
highlighting point of view), but he appeared to be outvoted. Larry
pointed out that <code>«»</code> etc were the least of a syntax highlighters
worries given that any <code>use</code>, <code>eval</code> or operator
declaration had the potential to morph any subsequent syntax. Piers
Cawley thought that truly accurate syntax highlighting would have
to be done in an image based IDE implemented in Perl because such an
editor would always know what rules were in scope for a given chunk of
code. A. Pagaltzis thought that this would definitely increment the
Smalltalkometer for Perl 6.</p>
<p>As discussion and exploration of this idea continued it became
apparent that people seem to like this particular weirding of the
language, and it certainly allows the programmer to disambiguate
things rather neatly. Luke even pointed out that this new approach
allows for calling a method on a list of values: <code>@list ».method</code>,
and to call a list of methods on a value: <code>$value.« @methods</code>.</p>
<p>Then the fun began. The issue is that <code>»</code> and <code>«</code> can also be
written <code>&lt;&lt;</code> and <code>&gt;&gt;</code> (but your POD processor hates you
for it). This leads to ambiguities like
<code>&gt;&gt;+&lt;&lt;=&lt;&lt;</code> (which are even harder to type in
a Pod escape) which can be parsed as <code>»+&lt;&lt;=«</code> or
<code>»+«=«</code>. Larry wondered if the problem arose because of trying to
make the <code>&lt;<code>lt</code></code> and <code>&gt;&gt;</code> alternatives look too similar
to the Unicode glyphs.</p>
<p>You know, looking at that last paragraph I can see why people think
Perl 6 is horribly scary. The thing is, you're not expected to use
constructions like that in real world programs all the time; but when
you're working out what a grammar should be you <i>have</i> to think of
all the nasty edge cases to see where things break.</p>
<p>Anyway, such nastiness led to the possibility of introducing a
'whitespace eating' macro which would allow for the introduction of
disambiguating whitespace. The front runner for this macro is <code>_</code>.</p>
<p><a href='http://groups.google.com/groups?selm=20040120085433.GA23075@babylonia.flatirons.org' target='_blank'>groups.google.com</a></p>
<a name='Comma operator'></a><h2>Comma operator</h2>
<p>Remember a few months ago when there was some discussion of replacing
the C style comma with some other glyph? If that were done, one of the
consequences would be that</p>
<pre>   @foo = 1,2,3;</pre>
<p>would fill <code>@foo</code> with three elements instead of just the one as it
does in Perl 5. Joe Gottman had a few questions about the implications
of that, and wondered if Larry had actually ruled on it. Larry ruled
that list construction would continue to require brackets (or, if
you're American, parentheses) and went on to discuss some further
implications of that.</p>
<p><a href='http://groups.google.com/groups?selm=000b01c3dfc4$bab7d620$e58f8445@carolina.rr.com' target='_blank'>groups.google.com</a></p>
<a name='Acknowledgements, Apologies, Announcements'></a><h1>Acknowledgements, Apologies, Announcements</h1>
<p>Thankfully, this section's normal service is resumed this week. The
only catch is, I can't think of anything to say.</p>
<p>However, if you find these summaries useful or enjoyable, please
consider contributing to the Perl Foundation to help support the
development of Perl. You might also like to send me feedback at
<i><a href='http://search.cpan.org/perldoc?<a href='mailto:p6summarizer@bofh.org.uk'>p6summarizer@bofh.org.uk</a>'>p<a href='mailto:6summarizer@bofh.org.uk'>6summarizer@bofh.org.uk</a></a></i>, or drop by my website (New! Improved!
listening on port 80! Still sadly lacking in desperately new content!)</p>
<p><a href='http://donate.perl-foundation.org/' target='_blank'>donate.perl-foundation.org</a> -- The Perl Foundation</p>
<p><a href='http://dev.perl.org/perl6/' target='_blank'>dev.perl.org</a> -- Perl 6 Development site</p>
<p><a href='http://www.bofh.org.uk/' target='_blank'>www.bofh.org.uk</a> -- My website, &quot;Just a Summary&quot;</p>
</div>
